home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19961006-19970104 / 000368_news@columbia.edu _Fri Dec 27 13:49:47 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.8.3/8.8.3) with ESMTP id NAA04825 for <kermit.misc@watsun.cc.columbia.edu>; Fri, 27 Dec 1996 13:49:47 -0500 (EST)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.8.3/8.8.3) id NAA03903 for kermit.misc@watsun; Fri, 27 Dec 1996 13:49:45 -0500 (EST)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: Not really a kermit question
  8. Date: 27 Dec 1996 18:48:45 GMT
  9. Organization: Columbia University
  10. Lines: 90
  11. Message-ID: <5a15md$8gs$1@apakabar.cc.columbia.edu>
  12. References: <5a119e$c6f@news1.voicenet.com>
  13. NNTP-Posting-Host: watsun.cc.columbia.edu
  14. Xref: news.columbia.edu comp.protocols.kermit.misc:6326
  15.  
  16. In article <5a119e$c6f@news1.voicenet.com>,
  17. Christopher Mosley <cmosley@voicenet.com> wrote:
  18. : I noticed that I had poor throughput during most of my sessions.
  19. : I tested this using mskermit and ckermit by using up/downloads during
  20. : serial dialin sessions. This is what I discovered:
  21. : 
  22. :  28.8 connection 115200 modem speed, windows 5, packet size 5000,
  23. :  42.bis compression,rts/cts. 
  24. : 
  25. As you might know, you can also squeeze another 20-25% throughput when
  26. transferring binary and/or precompressed files by using control-character
  27. prefixing (available in C-Kermit 5A(189) or later, MS-DOS Kermit 3.13 or
  28. later -- the current versions are 6.0.192 and 3.14, respectively).
  29.  
  30. :  1. A session fell into one of two categories either a throughput of
  31. :  3500 - 3900 cps or 6000 - 6500 cps for a text file (always the same file).
  32. :  The througput for a precompessed file was always ~3200 cps - this
  33. :  to assure that that varying line conditions did not account for the
  34. :  disparity. ~3200 was also the rate for a non-compressed session for
  35. :  any kind of file. During any one dial in session the cps did not change 
  36. :  from the slower realm to the faster or faster to slower.
  37. :  
  38. OK, so 3200 cps for a precompressed file, always.  That indicates, roughly,
  39. the actual capacity of the connection.  This is almost exactly what is
  40. expected (2880 cps / 8-bits-per-character = 3600 cps less about 11% LAPM
  41. (V.42) overhead = 3204 cps).   And the constancy of this figure rules out
  42. modulation downshifting of the V.34 connection.  So far so good.
  43.  
  44. Now a text file is usually quite compressible.  The degree to which it
  45. is compressed prior to transfer, then, all else being equal (and it seems
  46. to be) determines the throughput.
  47.  
  48. If sometimes the file transfers at 3500-3900 cps, and others at 6000-6500,
  49. this indicates that the the modems have successfuly negotiated a compression
  50. protocol in the latter case, but not in the former.  This can be verified
  51. by setting your modem to display its active protocols when it gives its
  52. CONNECT message, or by escaping back to the modem after connection and giving
  53. the appropriate command for displaying protocols.
  54.  
  55. :  2. Varing packet-lengths had no effect other than to slow or speed
  56. :  up everythimg by the expected amount.
  57. : 
  58. :  3.These results were basicly the same at all times: the likelyhood   
  59. :  of having a good or bad session was the same,  1 out of every 5 
  60. :  sessions was 'a good one'. This was during times of heavy or light
  61. :  load on the remote. It was possible to have a good session at times
  62. :  when the load on the remote was the heaviest and to have a bad
  63. :  session when the the lightest.
  64. : 
  65. :  4. The results were about the same for mnp compression.
  66. : 
  67. :  What I wonder.
  68. : 
  69. :  1.It seems that compression is occuring, but what is this 
  70. :  partial compression! ;-( , 3800cps for a file a file that would
  71. :  have a transfer rate of only slightly less (3200 cps)
  72. :  when a compression free connection was made?
  73. :      
  74. That's because Kermit protocol includes its own form of compression that
  75. is independent of the modem's.
  76.  
  77. : The reason I am posting here is the responses/suggestions I have gotten are:
  78. : 
  79. :   Don't use kermit. ?
  80. :
  81. Thanks for not listening to that one.  I think if you ran the same
  82. experiments with ZMODEM (which is, no doubt, what these people would tell
  83. you to use), you would get the same results for precompressed files, but you
  84. would probably get only the expected 3200 cps for text files, rather than
  85. the higher throughput that you got with Kermit.  That's assuming the clean
  86. and totally transparent kind of connection that is required for ZMODEM to
  87. work well, or at all.
  88.  
  89. :   Shouldn't use packet lengths of over 1024 on a hayes compatible modems. ?  
  90. : 
  91. That doesn't make any sense.  It's not the brand name or command set of the
  92. modem that's important, but rather its buffering and flow-control capacity.
  93. In general, the improvement from packet lengths over 1000 is marginal, but
  94. sometimes (almost in defiance of the underlying math) it can be significant.
  95. More often, a larger window size is more beneficial.  In all cases, of
  96. course, you can also improve throughput by "unprefixing" those control
  97. characters that are safe to send bare.
  98.  
  99. Kermit performance is discussed and analyzed in depth, with particular
  100. reference to V.34 connections, in Chapter 12 of the new second edition of
  101. "Using C-Kermit":
  102.  
  103.   http://www.columbia.edu/kermit/ck60manual.html
  104.  
  105. - Frank